上一篇文章，我談到重複點擊與交易防重，希望同一筆操作即使再次送出，也不會讓成員多付一次錢。

但防止重複，只是其中一部分。

當功能沒有順利完成時，成員眼前會看到什麼？他知道剛才送出的內容還在不在嗎？知道自己應該等一下、重新操作，還是找人協助嗎？

如果畫面只留下一句「發生錯誤」，這些問題其實都還沒有得到回答。

我希望微光的功能不只在成功時容易使用。出了狀況，也能讓人知道現在發生什麼，以及接下來能怎麼做。

使用者看到的，和程式知道的不是同一件事
程式遇到錯誤時，可能知道是哪個步驟失敗、哪個服務沒有回應，或哪一份資料不符合預期。

但使用者通常只看到操作沒有繼續。

他不一定需要知道底層原因，卻會在意一些更直接的事情。

「我的內容有送出去嗎？」
「金幣有沒有被扣掉？」
「現在再按一次，會不會重複？」
「我需要重新填嗎？」

因此，我想先從這些問題開始設計錯誤回應，而不是把程式裡的訊息直接搬到畫面上。

像是「連線逾時」可以描述一個技術現象，卻不能單獨說明交易結果。連線中斷之前，操作可能已經完成，也可能還沒開始。

不能因為程式遇到錯誤，就直接告訴成員所有事情都失敗了。

已收到、處理中、已完成，是不同的事情
我希望系統能區分幾個容易混在一起的狀態。

收到請求，只代表內容已經進來。正在處理，代表事情還沒結束。確認完成，才表示可以把結果當成已成立。

如果只是收到申請，就先說「已完成」，之後發現處理失敗，成員會不知道該相信哪一次回應。

反過來，已經確認完成的事情，也不該只因為後續通知失敗，就變成一筆失敗操作。

這些區分看起來像是用詞問題，其實需要程式裡真的有相對應的狀態。否則，文案寫得再精確，也可能只是猜測。

我想讓回應來自可確認的紀錄，而不是角色覺得現在應該說什麼。

不知道結果時，就不要假裝知道
有些情況確實無法立刻確認。

例如，送出操作之後連線中斷，系統暫時查不到最後結果。這時候，最不適合的做法，就是為了讓回覆看起來完整，隨便選擇成功或失敗。

我希望可以直接說明目前的限制。

假設有一筆購買結果尚未確認，回應可以是：

這筆購買的結果還在確認中。請先不要重新購買，可以透過本次交易紀錄查看狀態。

這只是文案例子，實際上必須真的有交易紀錄可查，才能這樣引導。

如果沒有查詢入口，就應該提供目前確實可用的協助方式，不能隨口說「稍後會自動通知」，卻沒有任何後續通知流程。

說明不知道，比給出錯誤的確定答案更有幫助。但也不能只停在不知道，還要讓人有下一步可走。

能不能重試，要看失敗發生在哪裡
「請稍後再試」很常見，也很容易寫。

但不是每一種錯誤都適合用同一句話處理。

查詢一份資料失敗，重新查一次通常不會改變帳戶內容。購買、發獎或提交任務，則可能已經產生部分效果，不能在結果不明時要求使用者從頭來過。

如果可以安全重試，就提供明確入口。需要沿用原本操作編號的重試，也應該由系統處理，而不是要求成員自己記住技術細節。

如果還需要確認結果，就先阻止重複執行，並提供查詢方式。

這也接回上一篇的防重設計。錯誤提示不能和實際流程互相矛盾：後端還不知道有沒有扣款，前端卻叫人再買一次，就可能把問題放大。

不要讓失敗順便吃掉使用者的內容
有些操作最讓人挫折的地方，不是失敗本身，而是剛才花時間填的東西不見了。

可能是一段任務回報，也可能是作品介紹。寫完送出，得到一句錯誤訊息，回去卻發現要全部重打。

如果介面與平台允許，我希望在確認送出之前，能保留必要的輸入，或至少讓成員方便複製自己的內容。

如果平台本身有做不到的限制，也需要在設計時考慮，而不是等到資料遺失後才說明。

不過，保留輸入也有界線。涉及私人資訊的內容，不能為了方便就無限期保存，更不能在公開頻道把整份內容貼回去。

要保留什麼、放在哪裡，以及何時清除，都需要和實際用途一起考慮。

角色可以有語氣，但不能把錯誤藏進故事裡
微光的角色有自己的口吻，錯誤回應也不一定要完全失去個性。

但如果功能失敗時，只說「命運的迷霧暫時遮住了道路」，成員可能不知道這到底是在演劇情，還是真的出問題。

我希望重要資訊先講清楚。

哪個操作沒有完成、目前確認到什麼、接下來應該做什麼，都比角色台詞優先。需要保留氣氛，可以在不影響理解的地方加上一點，而不是讓人先猜懂隱喻才能處理問題。

尤其涉及金幣、權限或提交結果時，更不能用模糊的故事語言帶過。

對方正在擔心自己的東西有沒有不見，不是等著欣賞一段錯誤訊息的文筆。

給成員的說明，和給維護者的線索要分開

使用者不需要看到完整的程式錯誤堆疊、內部路徑或服務設定。那些資訊通常無法幫助他完成操作，還可能暴露不應公開的內容。

但維護者確實需要足夠的線索，才能查明問題。

因此，我想把兩種資訊分開處理。

畫面上提供清楚的狀態、可行的下一步，以及必要的查詢編號。內部紀錄則保留排查需要的時間、操作階段與錯誤資訊，同時避免把密鑰或不必要的私人內容寫進去。

成員需要協助時，可以提供那個編號，不必重新敘述整個過程，也不用截下含有私人資料的畫面。

當然，編號必須真的能對應到紀錄。不能只是生成一串看起來像客服案件的文字，卻沒有人能用它查到任何事情。

說會處理，就需要真的有後續
「已通知管理者」是一句很容易讓人安心的話。

但如果程式只是顯示這段文字，並沒有成功建立紀錄或送出通知，就等於讓成員以為有人接手，實際上卻沒有人知道。

我希望這類回覆也必須有依據。

如果只是提供回報入口，就說明可以如何回報。如果已經建立待處理紀錄，才說已登記。需要人工確認的情況，也不要隨意承諾完成時間。

錯誤處理不一定能立刻解決問題，但至少要誠實交代誰會接著處理，以及目前是否真的有人接住。

這樣，成員才能決定是等待，還是需要另外尋求協助。

修好之後，也要確認原本那件事怎麼了
服務恢復正常，不代表之前失敗的操作都已經得到處理。

有人可能還在等獎勵，有人的提交停在中途，也可能存在已扣款但尚未交付的交易。

所以，我想把「功能恢復」和「受影響的事情已經處理完」分開確認。

修復之後，需要查清楚哪些操作可以繼續、哪些需要退回，以及哪些必須請成員重新提供資料。通知也應該對應實際處理結果，而不是只發一句「現在好了」，就把之前的問題一起關掉。

對使用者來說，他在意的通常不是服務終於能運作，而是自己剛才那件事，最後怎麼收尾。

出問題時，不讓人只能靠猜
我不能保證微光的功能永遠不會出錯。

但我希望即使出了狀況，成員也不用在沒有資訊的情況下，不斷重按按鈕、重新填寫，或到處詢問有沒有人知道發生什麼。

清楚的錯誤回應，需要可靠的狀態紀錄、安全的重試方式，以及真的存在的後續處理。它不是最後才補上的一句文案，而是功能的一部分。

如果一時還修不好，也至少讓人知道：哪些事情已經確認、哪些還不知道，以及現在可以怎麼做。

問題本身已經夠麻煩了。

我不希望使用者還得替系統猜一次答案。